The present invention is generally directed to allowing a directory to be renamed when the directory resides on a layered volume. A layering system is a tool that enables an operating system, user applications, and user data to be layered on the user's computing device. When using a layering system, layered applications and data are executed natively on the user's computing device without the use of a virtual machine or other sandboxed execution environment. This native execution will therefore cause the layered applications to appear, both to the user and to other applications, as if they were being executed in a “normal” manner. This is in contrast to many types of virtualization techniques such as terminal services and application virtualization where it is typically clear that the applications are executed in a separate environment.
U.S. patent application Ser. Nos. 14/719,248 and 14/719,256 are both directed to a layering system and provide a background for the present invention. The content of these applications is therefore incorporated by reference. It is noted that both of these applications are commonly owned and would not constitute prior art to the present invention. Therefore, this background should not be construed as admitting prior art, but should be construed as describing various features on which the present invention is based and that may even form part of the present invention.
As is described in the '248 and '256 applications, a layer is a collection of data or resources which enables the collection to be isolated or set apart from the data or resources in another layer. To summarize this layering, FIG. 1 provides simplified examples of a user data layer 101 and an application layer 102. It is noted that a layer containing an operating system may also exist. Each layer can be stored in a manner that allows the layer to be separately mounted for access. For example, each layer may comprise a separate partition of a disk (including of a virtual disk), a folder, a network share, etc. The ability to separately mount a layer allows the layering system to selectively provide access to particular layers. It will be assumed that the layering system determines that user data layer 101 and application layer 102 should be mounted in response to the user logging in to a computing device on which the layering system executes or which the layering system otherwise controls.
As shown in FIG. 1 and for simplicity, application layer 102 includes a single application, WINWORD.EXE, which is the executable for Microsoft Word. Word also requires a number of registry settings to execute properly, and therefore, application layer 102 also includes such registry settings. It is noted that these registry settings, which would normally be stored within the registry of the operating system, could be stored within application layer 102 in a registry hive. Of course, a typical installation of Word would require a number of other files and/or settings which are not depicted. Application layer 102 also includes layer metadata which describes the content of application layer 102 (e.g., which describes that the layer includes WINWORD.EXE and whatever structure is used to store the Word registry settings). This layer metadata is critical because it allows the layering system to quickly determine what exists on the layer.
User data layer 101 is structured in a similar way. However, as a user data layer, it stores the user's files which in this case constitute two Word documents: Report.docx and Summary docx. As with application layer 102, user data layer 101 may also store a number of other files including configuration files that may be particular to this user (e.g., a template file for Word). User data layer 101 also includes layer metadata which defines the content of the layer. Again, this layer metadata is critical because it allows the layering system to quickly determine what exists on the layer.
As mentioned above, a layer can be a separately mountable portion of a storage device (whether physical or virtual) such as a partition, folder, network share, etc. Accordingly, when the user logs on to a computing device, the layering system can mount layers 101 and 102 so that the user will have access to MS Word and his documents which are included in these layers. However, if a different user were to log in to the same computing device, the layering system could instead mount an application layer and user data layer pertaining to the different user so that the different user can only access the applications and user data defined in those layers.
The process by which the user accesses the data and resources included on each layer is provided in the '248 and '256 applications and will not be described in detail in this specification. By way of an overview, the layering system includes a file system filter driver and a registry filter driver which can function to intercept and redirect file system and registry operations as appropriate. In particular, these filters can be registered with the OS so that they will receive all file system and registry operations respectively. If a file system or registry operation pertains to content of a layer rather than to content of the file system or registry directly provided by the OS, the filters can redirect the operation to the corresponding layer. The '248 and '256 applications provide a number of examples of this type of redirection.
The result of this redirection is that, from the user perspective, the files of the layers do not appear to be stored in a different manner than any other file would typically be stored by the OS. For example, if the user data layer 101 were assigned a volume of E: the layering system could cause the files to appear as if they were stored in the typical C: volume. In other words, the fact that multiple volumes may be loaded is abstracted (and even hidden) from the user perspective. It is again reiterated that the use of layer metadata to define what is stored on each layer allows this process to be carried out efficiently as is described in the '248 and '256 applications.
FIGS. 2A and 2B each illustrate an example of how the layering system can function. Each of these examples involve the layering file system filter driver (or LFFD) 201 and its role in determining whether to redirect a file open request. It is noted that a similar process would be carried out by the layering registry filter driver (or LRFD) if the operation pertained to the registry.
As shown in FIGS. 2A and 2B, it will be assumed that the operating system provides a file system 200 for handling I/O to the various mounted partitions. It will also be assumed that the operating system has mounted a C: volume and that the layering system has mounted an E: volume that corresponds to user data layer 101. In the following description, the E: volume and user data layer 101 (or simply layer) will be used interchangeably. Because of the layering system, even though the E: volume is a separate volume from the C: volume, the contents of the E: volume will appear as if they were stored on the C: volume. In other words, the layering system can make it appear as if a single volume were mounted.
Accordingly, if the user selects to open the Report.docx file that is stored on the E: volume, a file open request 210 of C:\Docs\Report.docx may be generated. As is described in the '248 and '256 applications, LFFD 201 is registered as a filter driver for file system 200 and therefore will receive the opportunity to evaluate file open request 210. LFFD 201 can evaluate the target of file open request 210 against the layer metadata of the E: volume (and possibly against layer metadata of any other mounted layer) to determine if the request pertains to the layer. In this case, it will be assumed that the layer metadata indicates that the E: volume includes the path \Docs and that the Report.docx file is stored in the path. As a result, LFFD 201 can modify file open request 210 to create modified file open request 210a of E:\Docs\Report.docx. Modified file open request 210a is then passed to file system 200 which will open Report.docx from the appropriate location on the E: volume. LFFD 201 can perform this type of rerouting for any I/O that pertains to content stored on the E: volume. The determination of whether I/O pertains to content on a particular layer is based on the layer metadata for that particular layer.
FIG. 2B illustrates the case where LFFD 201 determines that a file open request 220 does not pertain to a layer (or at least does not pertain to a layer separate from the layer that includes the operating system). In this example, file open request 220 is directed to File.txt which is stored in a Downloads folder that is assumed to exist on the C: volume. Upon receiving file open request 220, LFFD 201 will evaluate the request against the layer metadata for the E: volume and determine that the E: volume does not include a path of \Downloads. Accordingly, LFFD 201 can allow file open request 220 to pass to file system 200 without modification since the request already includes the correct path to File.txt.
To summarize, LFFD 201 selectively modifies I/O requests so that they are directed to the appropriate layer. In the case of registry access, the LRFD would perform similar functionality to ensure that the registry access is directed to the appropriate layer. It is again reiterated that this rerouting is necessary because the layering system causes the layers to be hidden from the user's perspective while still being visible to the underlying file system.
Although a layering system allows layers to be employed in a substantially transparent manner from the user perspective, some problems exists. For example, due to the way in which the Windows operating system functions, a directory that resides on a layered volume that is different than the operating system volume cannot be renamed in a conventional manner FIG. 3 illustrates why this is so.
In FIG. 3, it is assumed that the computing system includes an OS layer as the C: volume and an application layer as the E: volume, and that, for the reasons indicated above, the contents of each layer is merged to appear as if it is all stored on the C: volume. It is also assumed that the E: volume includes a directory named Dir1 at the path EADir1. However, due to LFFD 201, the user will see this directory as C:\Dir1.
Operating system (OS) 301 is shown as receiving a request to rename CADir1 to C:\Dir2. For example, the user could right click on the Dir1 folder in Windows explorer, select “rename” from the drop-down menu, and then type Dir2. In response to this user input, OS 301 would commence a series of steps to complete the rename process. In step 1, OS 301 will send a request to file system 200 querying the location of the source directory which in this case is C:\Dir1. LFFD 201 will intercept this request and employ the metadata of the layers to determine that the directory Dir1 is actually stored on the E: volume. Therefore, in response to this query, LFFD 201 will respond with E:\Dir1.
Then, in step 2, OS 301 will send a second request to file system 200 querying the location of the target directory which in this case is C:\Dir2. LFFD 201 will determine that no directory Dir2 exists on any of the layers and will respond accordingly. As a result, in step 3, OS 301 will send a third request to file system 200 querying the location of the target directory's parent directory. In response to this third request, LFFD 201 can respond with C:\ (or could allow the request to pass through to file system 200 which would generate the same response). OS 301 can then generate the target of the rename operation by combining the parent directory (C:\) with the name of the new directory (Dir2) yielding C:\Dir2.
Once OS 301 has identified the source and target of the rename operation, it can then determine whether the source and target have the same volumes. In this case, the source is EADir1 and the target is CADir2. In cases where OS 301 will not allow a rename to occur across volumes (which is the case in Windows), the rename operation will fail since the source volume is EA while the target volume is CA. Due to the fact that OS 301 issues the requests in steps 2 and 3 independently of the request in step 1, LFFD 201 has no way of knowing that these queries for the location of the target pertains to an attempt to rename a directory on the E:\ volume. In other words, OS 301 does not provide any indication that the requests of steps 1-3 are related. LFFD 201 therefore has no way of knowing that it should specify the E: volume in its responses to the requests in either steps 2 or 3. For these reasons, the presence of LFFD 201 can prevent a directory on a layered volume from being renamed.